-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidate collectCustomPlots
#3466
Consolidate collectCustomPlots
#3466
Conversation
* have the code just have separate funcs for values creation
return iteration | ||
} | ||
const group = exp.name || exp.label | ||
const maxEpoch = exp.checkpoints.length + 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realized that using this way to get iterations breaks modified experiments. I need to understand a bit more on how iterations are originally gathered and see if it's even a good idea to get iterations through experiments...
If not, I either need to see if we can gather both plots through output data or rethink how to consolidate when plot plots require two different kinds of data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a discussion with Matt, we decided to keep the current implementation for now, since with a future change in the exp show output, it's likely that the current way of collecting iterations will no longer work anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Asked here: iterative/dvc#9170 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Answer here: iterative/dvc#9170 (comment)
@@ -105,8 +102,8 @@ export class PlotsModel extends ModelWithPersistence { | |||
this.customPlotsOrder = this.revive(PersistenceKey.PLOTS_CUSTOM_ORDER, []) | |||
} | |||
|
|||
public transformAndSetExperiments(data: ExperimentsOutput) { | |||
this.recreateCustomPlots(data) | |||
public transformAndSetExperiments() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[I] As discussed on the call this morning.
I think this can now be dropped and recreateCustomPlots
can be renamed/called instead of getCustomPlots
. It will get called from sendWebviewMessage
and it can be passed the selected revisions so that we only need to process the required experiments. Instead of processing them all and then filtering them afterwards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this pr already has approval and all other comments have been addressed, I completed this change in a separate pr, #3491
extension/src/plots/model/index.ts
Outdated
? this.experiments | ||
.getExperimentsWithCheckpoints() | ||
.filter(({ checkpoints }) => !!checkpoints) | ||
: this.experiments.getExperiments() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[B] collectCustomPlots
should take all experiments regardless of whether or not they have checkpoints. I think the best thing to do here would be call this.experiments.getExperimentsWithCheckpoints()
all the time as the checkpoints part of collectCustomPlots
will have a type guard in it anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the best thing to do here would be call this.experiments.getExperimentsWithCheckpoints() all the time as the checkpoints part of collectCustomPlots will have a type guard in it anyway?
This ternary expression is only there to filter out commit data. Technically, we are planning to add commit data to the metric vs param plots (see #3373) but I chose to keep things filtered since this is a housekeeping
pr. I don't mind just going ahead and adding the commit data in this pr though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I think about it, there is definitely an easier way to filter out experiment commits. Will update how we filter for now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I think about it, there is definitely an easier way to filter out experiment commits. Will update how we filter for now!
Originally was thinking I could filter by type
or commit
but looks like either of those could be unavailable. Ended up just renaming the variable to make things more clear.
return iteration | ||
} | ||
const group = exp.name || exp.label | ||
const maxEpoch = exp.checkpoints.length + 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Asked here: iterative/dvc#9170 (comment)
expect(data).toStrictEqual(checkpointPlotsFixture) | ||
}) | ||
|
||
it('should provide a continuous series for a modified experiment', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[F] This logic has been removed on purpose. Change is being discussed in [WIP] exp: refactor show behavior
PR. Link is further down.
* fullValues to values * use typeguard on ExperimentsWithDefinedCheckpoints
2/3
main
<= #3404 <= this <= #3491Resolves #3404 (comment)